home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94a.txt / 000041_icon-group-sender _Sat Feb 12 14:29:53 1994.msg < prev    next >
Internet Message Format  |  1994-08-19  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Sat, 12 Feb 1994 12:05:04 MST
  2. Date: 12 Feb 94 14:29:53 GMT
  3. From: swampler@noao.edu
  4. Organization: National Optical Astronomy Observatories, Tucson AZ
  5. Subject: Re: wishing for an Icon-like embedded language
  6. Message-Id: <1994Feb12.142953.9522@noao.edu>
  7. References: <CL0x83.BAr@walter.bellcore.com>, <1994Feb12.032054.26100@cs.rit.edu>
  8. Sender: icon-group-request@cs.arizona.edu
  9. To: icon-group@cs.arizona.edu
  10. Status: R
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13. In article <1994Feb12.032054.26100@cs.rit.edu>, nmw1638@cs.rit.edu (Nicolas M Williams) writes:
  14. |> In article <CL0x83.BAr@walter.bellcore.com> norman@flash.bellcore.com (Norman Ramsey) writes:
  15. |> >
  16. |> >that the world of C programs is not ready for an extension language
  17. |> >that requires a garbage collector.  Nonetheless, I would love to know
  18. |> >of anyone out there has thought about using Icon as an extension
  19. |> >language, or about how to identify a subset or design an extension
  20. |> >language with the ``flavor'' of Icon.
  21. |> 
  22. |> I suspect that given the structure of the language, a garbage
  23. |> collector for Icon could be "automatic", meaning that Icon keeps track
  24. |> of the number of references to each object, and collects them as their
  25. |> reference number drops to zero.
  26. |> 
  27. |> Or am I hopelessly wrong on this?
  28. |> 
  29. Well, Icon already has automatic GC, though not through reference counts (because
  30. of self-referential structures).  Instead Icon finds all useful data and discards
  31. the rest.
  32.  
  33. One reason why Icon hasn't been embedded is because of the sophisticated syntax -
  34. parsers for Icon tend to be quite large, compared to those for languages with
  35. (I know I'm going to regret this...) simple-minded syntax.  Of course, in this
  36. day of bloated programs, maybe no one would notice the increase caused by putting
  37. an Icon parser into an application!  (Hmmm, maybe someone should write an 'Icon
  38. Server' that can handle parsing and interpreting from multiple Icon clients...)
  39.  
  40. --
  41. Steve Wampler
  42. swampler@noao.edu
  43. Gemini Project (under AURA)
  44.